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Today’s  organisations  must  be  committed  to  the  continuous  pursuit  of  quality  improvement  as  a  requirement  for  survival. 

Traditionally,  quality  and  cost  have  been  perceived  as  a  trade-off  decision.  For  this  reason,  the  main  purpose  and  benefit  of 
measuring  quality  costs  has  been  to  demonstrate  that  improved  quality  and  lower  costs  go  hand-in-hand.  Through  collection 
and  analysis  of  these  quality  costs,  improvement  is  translated  into  a  language  management  listens  to  and  reponds  to:  money. 

This  article  provides  tools  and  techniques  to  help  infuse  cost  of  quality  (COQ)  concepts  into  the  project  team  activities  to  pro¬ 
mote  quality  improvement  throughout  the  full  project  life  cycle. 


There  have  been  many  changes  in  how 
DoD  project  management  applies 
quality  to  software  projects.  In  days  gone 
by,  there  was  a  separate  cost  for  quality 
attached  to  the  items  identified  within  an 
acquisition,  whether  for  software  or  for 
hardware.  As  acquisition,  project  manage¬ 
ment,  and  system  engineering  have 
evolved,  many  companies  have  replaced 
the  term  quality  with  other  terms,  such  as 
performance  and  best  practices.  Current  best 
practices  standard-bearers — such  as  the 
International  Organization  for  Standard¬ 
ization  (ISO),  the  Software  Engineering 
Institute’s  Capability  Maturity  Model® 
Integration  (CMMI®),  the  Project  Man¬ 
agement  Institute  (PMI),  and  the  IEEE — 
integrate  quality  into  everyone’s  work 
ethic  and  processes.  This  entails  creating 
integrated  product/process  teams  (IPTs) 
and  letting  the  individuals,  such  as  engi¬ 
neers,  logisticians,  configuration  man¬ 
agers,  testers,  and  project  mangers  (PMs), 
assume  responsibility  for  quality  within 
their  functional  processes. 

ISO  and  CMMI  argue  for  a  separate 
quality  group  to  maintain  objectivity. 
While  the  PM  has  the  final  responsibility 
for  quality,  a  quality  manager  can  be 
responsible  for  day-to-day  quality  by 
developing  and  implementing  a  quality 
effort.  Experience  has  shown,  however, 
that  when  funds  are  tight  and  time  is 
short,  the  quality  group  is  among  the  first 
cut  because  they  do  not  produce  a  physical 
product  for  the  customer.  Another  short¬ 
term  cost-saving  measure  is  for  the  PM  to 
select  someone  untrained  in  quality  assur¬ 
ance,  from  the  ranks  of  the  engineering 
staff,  to  be  the  quality  manager.  In  other 
cases,  there  may  be  no  identification  at  all 
of  a  separate  quality  process  owner  to 
oversee  dais  critical  area;  consequently,  the 
COQ  remains  hidden  in  other  project 

®  The  Capability  Maturity  Model  and  CMMI  are  registered  in 
the  U.S.  Patent  and  Trademark  Office  by  Carnegie  Mellon 
University. 


costs.  When  quality  is  just  another  sub¬ 
process,  it  has  to  fight  for  attention,  prior¬ 
ity,  and  funding  like  all  the  others.  When 
dais  occurs,  the  opportunity  to  identify 
and  correct  problems  early  in  the  life  cycle 
is  often  lost. 

This  maladaptive  application  of  quali¬ 
ty  principles  can  be  attributed  to  a  lack  of 
training,  management  support  for  quality 
processes,  and  adequate  quality  cost  mea¬ 
surement  systems.  It  is  more  likely  to 
occur  when  cost  and  schedule  become 
more  important  than  or  equal  to  quality. 

Figure  1  (taken  from  [1])  shows  the 
basic  cost  of  good  and  poor  quality. 

Evolution  in  the  Approach  to 
Quality 

In  decades  past,  the  focus  of  quality  was 
merely  finding  problems  at  the  end  of  an 
assembly  line  and  removing  the  defects 
before  shipping  to  the  consumer.  If  the 
product  did  not  meet  specifications,  it  was 
either  reworked  or  scrapped — both 
expensive  options.  This  approach  is  prone 
to  human  error  and  rarely  finds  all  defects. 
Furthermore,  this  quality  control  ap¬ 
proach  only  identified  the  defects  found 
through  a  random  sampling,  but  actually 
did  nothing  to  determine  the  root  cause  of 
the  problem  for  resolution. 

If  preventive  quality  measures  and 


rework  are  deferred  until  the  testing 
phase,  the  cost  of  change  is  40  to  100 
times  greater  than  if  the  defect  was  fixed 
when  it  was  created  [2],  The  testing  stage 
has  the  least  recovery  time  for  show-stopper 
problems  or  unexpectedly  large  amounts 
of  rework.  This  unpredictability  becomes 
a  large  contributing  factor  to  why  projects 
miss  their  schedules.  Furthermore,  this 
type  of  approach,  which  assumes  that 
doing  more  testing  leads  to  shipping  a  bet¬ 
ter  product,  only  works  up  to  a  point. 
With  pure  testing,  one  can  get  to  some¬ 
thing  approaching  5-Sigma  quality  (0.2 
defects  per  thousand  lines  of  code);  how¬ 
ever,  a  product  shipped  at  5-Sigma  is  per¬ 
ceived  as  inadequate  by  today’s  manufac¬ 
turing  standards  [3] . 

In  the  post- World  War  II  reconstruc¬ 
tion  years,  Dr.  W  Edwards  Deming  intro¬ 
duced  a  quality  program  that  simultane¬ 
ously  controlled  the  production  and  quali¬ 
ty  processes.  Unfortunately,  the  United 
States  did  not  adopt  these  principles  until 
the  1980s  with  the  introduction  of  the 
Total  Quality  Management  System.  Dem- 
ing’s  core  message — that  we  should  stop 
inspecting  defects  out  of  products  and 
start  building  quality  in — has  remained. 
The  common  thread  of  various  quality 
methodologies  is  that  the  project  team  will 
build  quality  into  the  system  design  and 
will  address  quality  continually  throughout 


Figure  1 :  Cost  of  Quality 
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die  life  cycle.  The  goal  is  to  identify  prob¬ 
lems  up  front  and  early,  allowing  corrective 
action  and  quality  prevention  to  take  place 
to  reduce  die  number  of  critical  defects 
found  at  die  end  of  die  assembly  line. 

This  goal  can  be  met  through  software 
quality  surveillance,  which  includes  walk- 
diroughs,  peer  reviews,  inspections,  test¬ 
ing,  IPT  structures,  as  well  as  any  method 
drat  identifies  quality  problems,  risks,  and 
operational  capability  weaknesses  as  early 
as  possible.  Approaching  quality  in  this 
manner  provides  early  corrective  action 
and  promotes  lower  quality  costs  upfront 
and  early,  thereby  reducing  end-of-pro- 
gram  cost  overruns  [4]. 

Today,  we  have  gone  a  step  furdier  by 
identifying  risks  which  may  have  the 
potential  to  change  engineering  require¬ 
ments,  operational  capabilities,  and  the 
quality  of  the  product.  In  the  spirit  of  risk 
management,  software  developers  can 
help  prevent  one  of  the  most  common 
causes  of  defects — ambiguous  require¬ 
ments — by  writing  comprehensive  accep¬ 
tance  tests  when  recording  each  require¬ 
ment.  Furthermore,  automating  these 
tests  and  running  them  as  part  of  frequent 
integration  builds  will  help  detect  defects 
when  they  happen. 

While  common  sense  says  that  pre¬ 
venting  defects  or  finding  them  when  they 
are  cheapest  to  fix  is  preferable  to  finding 
diem  at  the  end  when  they  are  many  times 
more  expensive,  several  software  develop¬ 
ment  projects  fail  to  write  tests  upfront, 
do  inspections,  or  perform  frequent  inte¬ 
gration — despite  the  benefits. 

Why  We  Don’t  Implement 

Preventive  Quality  Processes 

Implementing  quality  processes  is  tedious, 
time-consuming  work  in  most  environ¬ 
ments.  And,  time  is  money.  There  is  docu¬ 
ment  inspection  (usually  several  hundred 
pages)  and  writing  early  tests  for  critical 
requirements  at  the  beginning  of  a  pro¬ 
ject.  It  is  hard  to  keep  the  tests  up-to-date 
as  the  requirements  change  and  even  hard¬ 
er  when  you  realize  diat  you  have  to 
inspect  the  tests.  These  strategies  increase 
die  cost  of  implementing  quality  and  the 
return  on  investment  is  not  always  pre¬ 
dictable  with  a  high  degree  of  reliability, 
especially  when  the  requirements  and 
design  have  not  been  locked  in.  Thus,  it  is 
mind-wrenching  work  to  determine  which 
of  all  die  possible  strategies  for  imple¬ 
mentation  will  bring  the  best  value  to  the 
project. 

Carolyn  Fairbank,  CEO  of  the  Quality 
Assurance  Institute,  said: 

We’re  far  too  focused  on  product 


delivery,  not  process  capability. 
We’re  too  busy  trying  to  get  the 
product  out  the  door.  Granted,  this 
is  a  market-driven  phenomenon, 
but  we’ll  have  to  change  diat  dead- 
line-driven  attitude  to  one  of  good 
processes.  If  you  get  the  process 
right,  the  product  will  have  a  far 
better  chance  at  success.  Unfortu¬ 
nately,  many  IT  professionals  still 
don’t  quite  understand  die  concept 
of  process  management.  [5] 

According  to  Karl  Wiegers: 

We  do  far  too  much  pretending  in 
software.  We  pretend  we  know 
who  our  users  are,  we  know  what 
dieir  needs  are,  that  we  won’t  have 
staff  turnover  problems,  that  we 
can  solve  all  technical  problems 
diat  arise,  that  our  estimates  are 


“Today,  we  have  gone  a 
step  further  by 
identifying  risks  which 
may  have  the  potential 
to  change  engineering 
requirements,  operational 
capabilities, 
and  the  quality  of 
the  product  ” 


achievable,  and  that  nothing  unex¬ 
pected  will  happen.  Risk  manage¬ 
ment  is  about  discarding  die  rose- 
colored  glasses  and  confronting 
die  very  real  potential  of  undesir¬ 
able  events  conspiring  to  throw  our 
project  off  track.  [6] 


Risk  identification  requires  a  look  into 
die  future  as  to  the  potential  success  of 
die  program.  The  challenge  lies  in  the 
identification  of  risk  versus  current  prob¬ 
lems.  The  PMI  defines  risk  as  “an  uncer¬ 
tain  event  or  condition  that,  if  it  occurs, 
has  a  positive  or  negative  effect  on  a  pro¬ 
ject’s  objectives”  [7],  Current  problems  re¬ 
quire  attention  and  action  even  if  the 
immediate  remedy  is  to  defer  corrective 
action  until  later.  Risks  realized  may 
require  actions  that  lead  a  project  team  to 
proceed  in  a  different  direction  altogedier 


or  canceling  the  project  entirely.  Project 
teams  must  accept  some  risks  due  to  odier 
requirements,  conditions,  assumptions,  or 
constraints;  however,  if  a  project  team 
chooses  to  completely  ignore  risk,  diey 
gready  increase  the  probability  of  project 
failure. 

A  company’s  economic  status  or  con¬ 
dition  are  significant  factors  when  decid¬ 
ing  what  process  to  implement  to  track 
quality  cost  [8],  Pursglove  and  Dale  sug¬ 
gest  diat  the  profitable  nature  of  die  busi¬ 
ness  can  make  it  more  difficult  to  con¬ 
vince  management  of  the  need  to  track 
COQ  [9],  For  example,  having  more  engi¬ 
neers  and  fewer  quality  assurance  people 
on  a  project  can  be  great  for  a  company’s 
short-term  financial  success.  However,  if 
project  staff  members  do  not  build  in 
quality  from  the  start,  a  greater  reliance  on 
product  rework  results.  The  organization 
will  eventually  pay  for  the  inadequate  qual¬ 
ity  as  customers  identify  problems  with 
the  product  or  service.  Engineering 
changes  must  take  place  before  die  cus¬ 
tomer  deems  the  product  usable.  These 
engineering  changes  late  in  the  develop¬ 
ment  process  may  result  in  a  product  or 
service  that  does  not  quite  meet  the  origi¬ 
nal  intent  on  the  capabilities  delivery;  this, 
in  turn,  can  lead  to  lost  business.  If  this 
happens  on  a  recurring  basis,  the  compa¬ 
ny  may  experience  competitive  and  finan¬ 
cial  difficulties.  If  so,  a  company  may  be 
more  open  to  performing  an  assessment 
in  an  attempt  to  get  back  on  track.  Then, 
after  collecting  and  analyzing  data  diat 
reveals  a  quality  problem,  the  company 
finally  decides  to  track  quality  costs.  This 
may  also  be  the  time  when  the  company 
experiences  total  failure.  They  know 
somediing  has  to  be  done,  but  don’t  have 
a  well  thought-out  plan.  They  make  knee- 
jerk  decisions,  such  as  simply  canceling  the 
project  and  not  addressing  the  underlying 
quality  problems  in  dieir  processes;  that, 
in  turn,  causes  unintended  conflict  within 
the  organization. 

Not  having  a  clear  understanding  of 
the  actual  value  of  COQ  also  hinders  the 
adoption  of  quality  processes.  There  has 
been  a  persistent  misconception  in  the 
business  community  that  the  COQ  is  a 
cost  over  and  above  that  of  developing 
and  producing  a  project  to  meet  a  specific 
and  required  outcome  and  schedule.  The 
COQ,  regardless  if  it  is  software  or  hard¬ 
ware,  is  the  price  of  not  creating  a  quality 
product  or  service.  If  die  development 
process  was  perfect  widi  no  problems  and 
there  was  no  possibility  of  substandard 
service,  failure  of  products,  or  defects  in 
their  manufacture,  then  organizations 
would  have  no  expenditures  on  COQ. 
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Prevention 

Appraisal 

Represents  everything  a  company  spends  to  prevent  software 

Includes  the  money  spent  on  the  actual  testing  activity.  Any  and 

errors,  documentation  errors,  and  other  product-related  errors. 

all  activities  associated  with  searching  for  errors  in  the  software 

•  Staff  training 

(and  associated  product  materials)  fall  into  this  category. 

•  Requirements  analysis 

•  Design  reviews 

•  Early  prototyping 

•  Code  inspection 

•  Fault-tolerant  design 

•  Glass  box  testing 

•  Defensive  programming 

•  Black  box  testing 

•  Usability  analysis 

•  Beta  testing 

•  Clear  specifications 

•  Test  automation 

•  Accurate  internal  documentation 

•  Usability  testing 

•  Pre-purchase  evaluation  of  the  reliability  of  development  tools 

•  Pre-release  out-of-box  testing  by  customer  service  staff 

Internal  Failure 

External  Failure 

The  cost  of  coping  with  errors  discovered  during  development 

The  costs  of  coping  with  errors  discovered  after  the  product  is 

and  testing.  These  are  bugs  found  before  the  product  is 

released.  These  are  typically  errors  found  by  your  customers. 

released. 

•  Technical  support  calls 

•  Bug  fixes 

•  Answer  books  (for  support) 

•  Regression  testing 

•  Investigating  complaints 

•  Wasted  in-house  user  time 

•  Refunds  and  recalls 

•  Wasted  tester  time 

•  Interim  bug  fix  releases 

•  Wasted  writer  time 

•  Shipping  product  updates 

•  Wasted  marketer  time 

•  Warranty,  liability  costs 

•  Wasted  advertisements 

•  Public  relations  to  soften  bad  reviews 

•  Direct  cost  of  late  shipment 

•  Lost  sales 

•  Opportunity  cost  of  late  shipment 

•  Lost  customer  goodwill 

•  Supporting  multiple  versions  in  the  field 

•  Reseller  discounts  to  keep  them  selling  the  product 

Table  1 :  COO  Data  Points 


COQ  is  the  sum  of  costs  incurred  in 
maintaining  acceptable  quality  levels  plus 
the  cost  of  failure  to  maintain  that  level 
(cost  of  poor  quality),  and  typically  ranges 
from  15-25  percent  of  total  cost  [10]. 

Philip  B.  Crosby’s  “Quality  Is  Free” 
concept  [11],  identified  two  main  cate¬ 
gories  of  quality  costs:  conformance  costs 
(cost  of  good  quality),  and  nonconfor¬ 
mance  costs  (cost  of  poor  quality). 

Conformance  costs  include  prevention 
and  appraisal  costs;  nonconformance 
costs  include  internal failures  as  well  as  exter¬ 
nal  failures  (Table  1,  from  [12]).  A  defect 
found  early  in  the  project  prior  to  cus¬ 
tomer  delivery  is  termed  an  internal  fail¬ 
ure.  A  defect  identified  after  the  product 
has  been  deployed  to  the  customer  is  an 
external  failure.  External  failures  can  also 
include  incompatibility  of  the  software 
with  legacy  software  installed  in  the  field, 
or  a  lack  of  commonality  between  redun¬ 
dant  systems. 

Beyond  not  clearly  understanding 
COQ  concepts,  key  decision  makers  in  an 
organization  may  lack  knowledge  in  deter¬ 
mining  quality  costs  and  the  principles  for 
collecting  quality  costs.  Without  knowing 
what  quality  principles  are,  an  individual 
or  organization  may  have  no  idea  where  to 
place  their  focus  to  obtain  quality  costs. 
The  organization  can  remedy  this  either 
by  ensuring  that  a  quality  curriculum  is 
included  in  the  training  for  project  staff 


and  senior  leadership  or  by  hiring  a  quali¬ 
ty  consultant  to  guide  the  organization. 

Getting  a  COQ  System  in 
Place 

Herb  Krasner  and  Dan  Houston  explain 
that  companies  need  to  answer  three  ques¬ 
tions  [13]: 

1 .  How  much  does  poor  software  quality 
cost? 

2.  How  much  does  good  software  quality 
cost? 

3.  How  good  is  our  software  quality? 
Once  these  questions  are  answered, 

the  project  team  can  compare  quality  costs 
to  overall  software  production  costs  and 
software  profits,  and  to  benchmarks  and 
norms.  They  can  also  better  analyze  prod¬ 
uct  quality  to  improve  their  competitive 
situation,  measure  improvement  actions 
and  the  bottom-line  effect  of  quality  pro¬ 
grams,  visibly  see  previously  hidden  costs 
related  to  poor  quality,  and  more  clearly 
see  the  economic  tradeoffs  involved  with 
software  quality. 

Even  if  die  project  team  cannot  mea¬ 
sure  all  of  these  costs  with  a  high  reliance, 
a  COQ  model  quantifies  (for  management 
and  executives)  the  amount  of  money 
being  lost  on  fixing  defects  and  delivering 
poor-quality  products.  This,  in  turn,  nega¬ 
tively  affects  their  bottom  line.  That  pro¬ 
vides  motivation  and  impetus  for  imple¬ 
menting  preventive  quality  measures. 


In  order  to  feed  decision  makers  those 
costs  with  some  degree  of  legitimacy,  a 
life-cycle  model  has  been  developed  to 
guide  this  work  (Figure  2,  next  page). 

Note:  If  no  data  source  exists  for  the 
collection  of  costs,  then  the  project  team 
will  have  to  use  some  type  of  analytical 
technique  to  develop  a  cost  estimate 
model.  With  this  model,  the  team  should 
be  able  to  establish  the  cost  estimates  for 
the  appropriate  quality  categories. 

Capturing  COQ 

This  step  in  the  life  cycle  is  twofold:  (1) 
identify  the  costs  and  (2)  determine  a 
method  for  entering  costs  into  an 
accounting  system  that  tracks  them 
throughout  system/service  development. 

When  quality  costs  are  initially  deter¬ 
mined,  the  categories  included  are  the  vis¬ 
ible  ones. 

Oftentimes  it  is  what  you  do  not  know 
that  can  hurt  a  project.  Software  quality 
costs  are  not  always  easy  to  identify  with¬ 
in  programs.  Software  has  maity  hidden 
costs  that  may  not  be  readily  apparent  to 
the  project  manager.  These  are  shown 
below  the  water  line  in  Figure  3  (next 
page,  adapted  from  [1]  and  [14])  and  in  the 
expanded  Figure  4  list  on  page  27. 

As  an  organization  internalizes  a 
broader  definition  of  poor  quality,  the 
hidden  portion  of  the  iceberg  becomes 
apparent.  Identifying  these  costs  opens  a 
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Figure  2:  The  Life  Cycle  of  COQ 


door  of  opportunity  and  the  project  team 
can  then  implement  processes  to  avoid 
more  costly  expenditures  later  in  the  pro¬ 
ject.  Furthermore,  the  team  increases  the 
probability  that  the  product/service  will 


be  acceptable  to  the  customer  within  all 
required  elements  and  functions  that  the 
product/ service  is  supposed  to  deliver. 

A  proper  focus  on  quality  entails  iden¬ 
tifying  and  funding  quality  costs  and  insti¬ 


tutionalizing  quality  processes  at  the  very 
beginning.  It  also  requires  that  quality 
experts  supply  to  management  an  estimate 
of  the  total  quality  costs,  good  or  bad. 
Management  uses  the  information  ob¬ 
tained  through  the  quality  initiative  as  a 
tool  to  adjust  funding  allocations.  Once 
the  quality  experts  have  gathered  data, 
upper  management  can  determine  with  a 
clearer  picture  where  to  concentrate  qual¬ 
ity  efforts  and  funding  for  eventually 
achieving  a  greater  positive  impact  and 
promoting  a  successful  project. 

While  the  traditional  tnethod  is  the  most 
used  method  in  collecting  costs  related  to 
quality  (according  to  the  American  Society 
for  Quality),  organizations  can  also  use  the 
defect  document  collection  method,  the 
time  and  attendance  collection  method,  or 
the  assessment  method.  The  PM  and  the 
quality  manager  (if  the  PM  has  designated 
one  for  the  project),  will  have  to  do  a  cost- 
benefit  analysis  to  determine  which 
method  is  the  best  fit  for  the  organization 
and  project,  given  available  resources. 

Feed  Total  COQ 

Having  identified  costs  and  a  method  for 
tracking  them,  diligent  data  collection  is 
now  required.  This  also  includes  incorpo¬ 
rating  previously  unidentified  costs 
revealed  during  ongoing  activities  that 
now  require  tracking. 

Review  the  Contract 

The  quality  group  must  be  conscious  of 
the  legal  terms  as  well  as  the  performance 
of  specific  tasks  within  any  contract  to 
support  product/ service  development 
and  delivery.  They  should  be  familiar  with 
specifics  to  ensure  the  contractor  is  com¬ 
pleting  required  tasks  throughout  the  life 
cycle  of  the  product.  There  may  be  spe¬ 
cific  tasks  that  occur  sporadically  during 
the  development  cycle  and  therefore 
require  a  more  concerted  follow-up. 

Review  the  Cost  Accounting 
Approach 

On  a  periodic  basis,  it  is  important  to 
ensure  that  the  cost  accounting  process 
and  repository  adequately  track  all  perti¬ 
nent  cost  information  collected  on  work 
currently  performed. 

The  system  may  require  refinement 
due  to  new  requirements  and/or  addition¬ 
al  costs  not  identified  at  the  start  of  the 
life  cycle.  This  may  also  require  changes  in 
the  data  collection  method. 

Review  Existing  Data  Sources 

It  is  also  important  to  ensure  that  the 
sources  used  for  cost  data  provide  the  best 


Figure  3:  The  Iceberg  Model  of  COO 
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available  data  in  terms  of  validity  and 
accuracy.  Do  not  hesitate  to  switch  to  a 
better  data  source  if  it  provides  data  that 
will  give  a  more  accurate  picture  of  where 
the  project  stands  at  a  particular  point 
within  the  process. 

Review  Costs  Proposed 

As  development  continues,  hidden  costs 
not  identified  at  the  start  will  reveal  them¬ 
selves.  Track  these  costs  along  with  those 
originally  proposed  to  facilitate  budget 
adjustments  and  to  recalculate  the  return 
on  investment  projections  in  order  more 
effectively  manage  expectations. 

Studies  (such  as  [9])  indicate  that  the 
further  along  in  the  process  quality  is 
worked  into  the  product  or  service  that 
the  higher  the  COQ  will  be.  The  project 
team  should  try  to  reduce  the  overall  cost 
of  each  product  or  service  by  establishing 
the  optimum  level  of  preventive  and 
appraisal  costs  that  minimizes  resultant 
error  costs.  The  net  result  of  quality 
improvement  should  be  a  reallocation  of 
costs  across  the  COQ  categories  resulting 
in  a  reduction  in  the  overall  COQ.  An 
example  of  this  [15]  is  shown  in  Figure  5. 

Apply  Professional  Judgment 

This  is  the  time  for  analysis  of  all  infor¬ 
mation  gathered  regarding  the  health  of 
the  program.  By  pushing  this  data  and 
analysis  to  the  appropriate  project  deci¬ 
sion  makers,  they  can  make  informed 
decisions  on  how  to  proceed  to  ensure 
project  success. 

Conclusion 

At  first  glance,  an  individual  might  be 
prone  to  drink  that  collecting  quality  costs 
is  expensive,  adding  unnecessary  costs  to 
the  product  or  project.  Quality  is  not  free 
in  that  you  have  to  make  an  up-front 
investment  in  time,  money,  and  effort. 
However,  if  performed  properly  over  the 
full  life  cycle  of  the  project,  you  can 
recoup  the  resources  expended  for  quality 
processes  by  avoiding  rework  later  in  the 
project  life  cycle.  By  communicating  the 
quality  story  in  terms  of  dollars,  you  can 
enlist  the  help  of  senior  management  to 
infuse  quality  processes  throughout  the 
project  life  cycle  and  contain  project  costs 
for  the  long  haul.  As  with  many  project 
management  standards  and  guides  (e.g., 
[7]),  collecting  quality  costs  is  like  project 
planning;  it  is  cheaper  to  properly  plan 
than  it  is  to  plan  a  little  and  fail  a  lot.^ 
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